1. Field of the Invention
The present invention relates to a communication control apparatus, and more particularly to such an apparatus for use in a telecommunications network system for controlling Quality of Service (QoS), such as communication bandwidth, delay time or packet drop rate, on a communication terminal device when connected to the network and executing communication application software.
2. Description of the Background Art
Today, there are a wide variety of communication application services, such as telephony, WEB (world wide WEB) browsing, file transfers and VoD (Video on Demand). Such communication application services also require establishing various kinds of QoSs, such as communication bandwidth, delay time and packet drop rate. Accordingly, if it is possible to accomplish appropriate QoS specific to communication application services, then the user can enjoy communication application services with higher QoS or Quality of Experience (QoE).
For example, a case will now discussed where via the Internet a motion picture stream is being received and reproduced in foreground and, at the same time, free software, used later on, is downloaded in background. If the communication bandwidth is not sufficient, a communication bandwidth, which is necessary for receiving motion picture streams requiring higher levels of quickness and continuity, is first reserved. Subsequently, over the remaining communication bandwidth, free software not requiring high levels of quickness and continuity is downloaded. Interruption of the reproduction of motion picture streams will thereby be infrequent and the QoE will be improved.
Conventionally, solutions for utilizing network resources are proposed to establish QoS specific to communication application services. For example, there are an IntServ (Integrated Services)-based architecture and a DiffServ (Differentiated Services)-based architecture.
In the IntServ-based architecture, communications are performed with a communication bandwidth reserved between endpoints, e.g. between a terminal unit and a server on a provider network. A typical protocol of the IntServ is RSVP (Resource reSerVation Protocol) regulated in RFC (Request For Comments) 2205. In the IntServ-based architecture, a communication bandwidth can reliably be reserved, but every communication device between the endpoints must be constructed so as to enable a certain protocol available. If any of the communication devices between endpoints does not comply with the certain protocol to be used, the IntServ system would not operate. Today, devices complying with this architecture are not widespread, and the IntServ-based architecture is rarely used.
In the DiffServ-based architecture, communications are performed with classes of service (CoSs) set for plural kinds of communication application services and with a QoS class selected which is appropriate for a communication application service. Typical protocols of the DiffServ-based architecture are regulated in RFC2474. Communication devices capable of coping with the DiffServ-based architecture operate according to values set in the DSCP (Differentiated Services Code Point) of the TOS (Type Of Service) field of packets while other communication devices not complying with the DiffServ-based architecture perform communications with the QoS class neglected. The DiffServ-based architecture is based on the policy that priority is given first to the possibility of delivering data, at any rate, rather than the reliable reservation of QoS so as to operate the system to establish the required QoS with best effort.
Incidentally, as prior arts preceding the present invention, there are Japanese patent laid-open publication No. 2009-049458, and Tomoaki Tsugawa, et al., “Implementation and evaluation of an inline network measurement algorithm and its application technique”, the Institute of Electronics, Information and Communication Engineers (IEICE), Technical Report of IEICE, Information Networks 105 (472), pp. 61-66, Dec. 8, 2005.
Under the current circumstances, not only the IntServ-based architecture, which requires that every communication device complies with a certain protocol, but also the DiffServ-based architecture, which does not always require that communication devices comply with a certain protocol, are not sufficiently widespread and utilized. The circumstances might be caused by the following problems.
As the first problem, most of communication application software, which may sometimes simply referred to as “application”, are not adapted for controlling the QoS on communications. In addition, as the second problem, if an application is adapted for controlling the QoS, a request issued by the application is not always appropriate. For example, an application, which is not important in practice, e.g. in level of quickness and continuity, may issue a request for communications with top priority. In that case, if communication devices unconditionally accept such a request from the application, traffic congestion may be caused over the whole network, and the QoS of really important communications, e.g. requiring higher levels of quickness and continuity, may deteriorate.
As the third problem, since communications requested by one and the same application may be higher in priory in some cases and lower in other cases, it may be impossible to definitely allot priority to the communication to the kind of the application. For example, the communication priorities may differ from a case where the WEB browser is currently downloading data on a website interesting to a user on communications, i.e. information requiring a higher level of quickness is being received, to another case where the WEB browser is prefetching and downloading in advance in background data which is more probable in being used later, i.e. information requiring a lower level of quickness is being received.
As the fourth problem, the terminal or its OS (Operating System) does not always comply with the QoS control. In addition, as the fifth problem, the QoS control functions, which include a function of setting a communication bandwidth and delay time for each process, may not be unified between the network devices. Moreover, as the sixth problem, even if the state of usage of the network is notified to a terminal unit, its OS or an application running on the terminal unit, they do not always have a mechanism of utilizing the information transmitted to the terminal unit for QoS control. Furthermore, as the seventh problem, even if the network equipment can be notified of control information with the terminal unit or its OS, the network equipment does not always have functions of recognizing an application used by the user and the state of utilization of the network, and of then calculating the operational variables for optimum control of the QoS.
Some of the first to seventh problems may be overcome even by existing solutions. For example, since most of ATM (Asynchronous Transfer Mode) terminals can perform communications with a specified QoS, the fourth problem may be solved by using such ATM terminals. Furthermore, the fifth problem may be solved by using network nodes having functions based on the DiffServ-based architecture.
However, networks widespread under the current circumstances are not adapted to provide a plurality of applications with QoSs appropriate for the respective resources. Because, the first to seventh problems are interrelated with each other so that solutions to the first to seventh problems would, when combined, not result in appropriate operation as a whole. For example, when a plurality of ATM terminals are prepared and connected to the nodes of DiffSery system, the fourth and fifth problems would both literally be solved. However, in practice, such a connected system would not perform communications with the QoS well controlled because general nodes of the DiffSery system have no mechanism of recognizing requests for the QoS of ATM terminals.